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1-0 SDM_OVERVIEW AND SUMMARY 


Lol INTRODUCTION 


The purpose of this SDM USERS GUIDE is to set forth the 
proceduress techniquess and toots to be used by SDD (Sunnyvaie 
Development Division) personnel in developing Advanced Systems 
Release 2 software products. 


The primary purpose of an SDM is to assure that a project will 
meet requirements on schedute and within budgets as agreed to 
between management and the project. 


The SDM proposed in this document is an evolutionary outgrowth 
of SDMs in use in Controt Data since the earty 1970s (Peterson 
19735 Metzger 19731. 


This documents to the extent that it conflicts with Corporate 


Standard 1.01.106 "Software Development Model™» constitutes a 
proposal to update the methodology of that Standards insofar 
as that Standard is applicable to the development of Systems 
Softwares 


While this document is concerned with current practices in 
SDD» it is more concerned with how current practices can be 
shaped into a coherent and systematic SOM. 


162 WHAT.IS_SDM2 


SDM is the famity of internal documents,s techniauess and tools 
by which requirements become design and design becomes 
releasable code supported by published external documents. 


For the Sunnyvale Development Divisions requirements» designs 
implementations evaluations and publication activities are 
recorded in the following family of documents: 


ae Requirements documents (controltied via DCS) 


- AO/R (CY180 Architectural Requirements/Objectives) 


-~ SIS (System Interface Specification) 
- GDS (General Design Specification) 
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- DR (Design Requirements) 
- ERS (External Reference Specification) 


be Design documents (controltted via DCS) 
- GID (General Internal Design) 


Ce Implementation documents (code controfted by code 
transmittal and PSR proceduress documents via DCS) 
- Pt (Program Library of documented source code) 
- PSR corrective code 
- Baseline documentation changes 
-~ IMS (Internal Maintenance Specification) 


d. Evaluation documents (PSTP controtted via DCS» others 
controlled by management procedures) 
~ PSTP: (Product Set Test Plans for each code 
Release} 
- BER (Build Evaluation Report) 
- Approved Reviews (by Development and Evaluation) 
of Publications drafts of manuals. 


@e. Publications (controlled by Publications procedures) 
-~ Reference Manuals 

Dperators Guides 

Instattation Handbook 

Users Guides 

"Instant”™ Reference booktets 


oe 


While the generation of these documents is basically 
chronological due to tlogical dependencies inherent in the 
order given above, there is also an iterative process at work 
because as we learn mores we may have to revise previous 
documents. That iss requirements "drive" design and design 
"drives" code. Howevers refinement of design can tead to 
revision of requirementss and refinement of code can tead to 
revision of design (and sometimess revision of requirements). 


1-3 BASELINE. DOCUMENTS» DAP*S2_BSL?52_955%S52_AND_RSE*S. 
Many of these documents are referred to as Baseline Documents» 
which are of two kinds? internal and externais subject to 


different sets of policies. 


Internal Basetine documents ares 


- ADSR 
- S15 
- 6DS5 
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- OR STTJ 1 

- ERS STTJ 2 

- GID STTJ 3 

- PSTP STTJ 4 

- IMS STTJ 5 

sy 6 

External Baseline documents are products of Publications: ST 7 
- Reference manuats SSTTJ 8 

- Operators guides STTJ 9 

~ Instattation Handbook STTJ 10 

5 11 

DAPs are usuatty generated during the Analysis and Design $ 12 
activitiess each DAP addressed to a particular issue. The 13 
author of a DAP should identify in the DAP the section(s) of 14 
baseline document(s) which will be modified if the DAP is 15 
approved. The content of an approved DAP should result in a 16 
BSL (baseline change) with change pages to an internal 17 
(possibiy external) baseline document. 18 
19 

Q8Ss (Quotation Special Software) and RSEs (Request Software SI 20 
Enhancement?) which become features of standard software should 21 
be handied as are DAPs.~ A BSL with change pages for affected 22 
documents should be generated. 23 
24 

25 

1.4 {OFTWARE DEVELOPMENT. PHASES H2 me 
Initial development phases are product/project oriented for a SI 28 
given version or release: 29 
- Feasibility Phase SSTTJ 30 

- Definition Phase STTJ 31 

- Analysis Phase STTJ 32 

- Design Phase STTJ 33 

- Imptementation Phase STTJ 34 
These phases (plus the Feature Test Plans which Is product SI 35 
oriented) are covered in the Project Plan. 36 
37 

Concluding development phases are Product Set oriented toward SI 38 
a particular release? 39 
- Evaluation Phase SSTTJ 490 

- Publications Phase. STTJ 41 

~- Reilease-activity Phase STTJ 42 

S 43 

In the pasts maintenance has sometimes been considered a SI 44 
foltow-on phase. Howevers for Advanced Systemss AD&C is 4&5 
directing that maintenance be handied in the same way that a 46 
new wersion would be: Go back to the Feasibility Phase and 47 
cycle again through al! phases in an orderty manner. This 48 
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1.4 SOFTWARE: DEVELOPMENT PHASES 


procedure should aid the. preservation of structural integritys 
which tends to erode over time ({Beltady 1979» VanHorn 1980]. 


ae Feasibility Phase 


Deliverable documents are: 
- Project Plans chapters 1 (Definition Phase 
Pian) and 7 (References) 
~ GDS (first version) or other documentation 


describing the product in general terms for 


PLM and Marketing approval 
The Feasibility phase begins when Management 
initiates the preparation of a GDS or equivalent 


documentation for submission to PLM and 
Marketing. . 
The Feasibility Phase concludes when all 


deliverable documents are approved. 

GOS (at feast a first version) is preferable to an 
ad hoc document because a GDS will be produced 
fater any ways based upon the ad hoc documents. 
Howevers conditions vary among projectss and ad 


hoc documents may be more suitable to particular. 


circumstances than a SDS. 

The purpose of the Feasibility phase is to 
determine that there is a need In the CDC product 
line for the proposed products and to reach a 


general consensus upon the requirements fors and. 


the architecture of» the proposed product. 


be. Definition Phase 


Deliverable documents are: 

- Project Plans» chapter 2 {Analysis Phase 

Pian) 

- GDS (final version) 
The Definition phase begins when management 
initiates the preparation of either deliverabie 
document. 
The definition phase conctudes when afl 
deliverable documents are approved. 
The purpose of the Definition Phase is to define 
features, performances and architecture of the 
product in sufficient detail to provide direction 
to the Analysis phases during which aif 
requirements will be expticated. 


Ce Analysis Phase 


—~™- . 


Deliverable documents: ares: 
- Project Plans chapter 3 (Design Phase Plan) 
- DR 
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1=5 


09/23/81 


- ERS 
- GID chapters ls 29 3:2 and 5 (Analysis Spec 
and Data Dictionary) 

- The Anatysis Phase begins when management 
initiates the preparation of one or more of the 
Analysis Phase deliverable documentss based upon 
evidence that the GDS is sufficientiy stabtized to 
provide direction for the Analysis Phase. 

- The Anatysis Phase conctudes when all deliverable 
documents are approvedse 

- The purpose of the Analysis phase is to make 
explicit alii feature requirementss performance 
requirementss interface requirements» and to 
insure that the proposed product architecture 
supports all known requirements and aif’ envisioned 
future features and future requirements. 


de Design Phase 
- Deliverable documents are: 

- Project Plans chapter & (Implementation 
Phase Pitan) and chapter 3 {Feature Test 
Pian) 

- 61D chapter 2 {Design Spec and revised Data 
Dictionary) 

- Internat and external document BSLs required 
by Publications for manuals supporting 
releasable code. 

-~ The Design phase begins when management initiates 
the preparation of either deliverable document. 

~ The Design phase concludes when all detiverabte 
documents have been approved. 

- The purpose of the Design phase is to document 
explicitly the design of the product prior to 
coding.e . 


@.e Implementation Phase 
- Deliverable documents. are: 
- Sourse code PL 


- IMS. 
~ Reviews of drafts of (external) baseline 
manuals 


- The Implementation phase begins when management 
initiates it. . 

- The Implementation. phase concludes when 
detiverabtes are approved. 

- The purpose of the Imptementation phase is to 
generate releasable code that meets all 
requirements and to provide I[€E and Pubs with 
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documentation supporting the successful completion 
of their tasks. 


f. Evaluation Phase 
- Deliverable documents are: 


- Project Plan chapter 5, Feature Test Plan 

- PSTP (Product Set Test Pians formerty System 
Test Plan in SOD) 

- System Test Plan (ARPD) 

- Test base programs and data 

-~ BER (Build Evatuation Report) 


- Testing activities are of two kinds: preparing 
test plans and tests» and testing code. 


- Feature Test planning begins with the 
preparation of the Project Plan chapter 5 
(Feature Test Plan)ds and continues with the 
generation of test code and datae 

- Product Set Test planning begins when 
management initiates the preparation of the 
PSTP (based upon ali Feature Test Plans of 
all products of the set)s and continues with 
the generation of test code and data. 

- System Test planning begins when management 
initiates the preparation of the System Test 
Plane 

- Testing of code begins when management 
initiates the testing of transmitted PL or 
PSR code for a release, 


- Testing phase for a4 release conctudes when 
management accepts the BER and approves code for 
release, 

- The purpose of the Feature Test Phase is to insure 
that the product code performs correctiy according 


to 


functions specified in the requirements 


documentation and the publications. 

- The purpose of Product Set Testing (SDD) is to 
insure that the versions of products in the 
to-be-released set function: together correctly. 

- The purpose of the System Test Release activity is 


to 


insure that all of the software of the Release 


operates together as a system and meets 
performance requirements.. 


ge Publications Phase 
- Required detiverable documents are: 


- Manuats Test Plan 
~- Reference Manuais (or. Release Revision 
packets) 
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- Operator Guides 

- Instattation Handbook 
Optional deliverable documents are: 

~ Users. Guides 

- Instant Reference booktets 
The Publications phase for a release begins when 
management initiates preparation of (or revision 
of) a documents following receipt from Development 
or Design. of supporting documentation (leeges an 
ERS) to warrent pubtications activity and 
providing resources are availabie. 
The Publications phase for a code release ends 
with submission of manual originals to Corporate 
Printinge 


The purpose of the Publications Release activity 


is to support released code with external user 
manuals. 


he Release-activity Phase 


Deliverabtes 
- PLs avaitable from SMD (Software 
Manufacturing Division) 
- External Publications manuals are avaitablie 
from LDS (Literature Distribution Service) 
- All: Retfease Bulletins are available: 
SAB (Software Availability Bulletin) 
SRB (System Release Bulletin) 
FAM ( Feature Abstract Memorandum) 
The Release Phase begins when management initiates 
steps to move the deliverables from Develooments 
Evaluations and Publications to the organizations 
that distribute the deliverables to customers. 
The Release Phase concludes when refease materials 
are delivered to customers. 
The purpose of the Release Phase is to insure that 
customers receive timely and coordinated service 
in connection with new releases. 
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200 DEVELOPMENT PHASES SSH1 
3 

4 

5 

6 

7 

8 

2e1 EEASIBILITY PHASE H2 a 
The purpose of the Feasibility Phase is to explore the I 11 
feasibiffity of a proposed product or product enhancement from 12 
the joint viewpoint of Marketings PLMs and Development. 13 
“Feasibility” there means "market feasibility" Cis there a 14 
profitable market for the proposed product?) rather than 15 
"engineering feasibitity"® (can the product be built to 16 
specifications?)» which is explored in the Definition Phase. 17 
18 

For some products» such as those for which there is agreement SI 19 
to meet an existing ANSI standards the Feasibility and 20 
Definition phases are relatively brief. For other products» 21 
such as Data Management and Networkss there may be much effort 22 
required to define a product wel! enough to provide design 23 
direction: for the preparation of Analysis Phase documents (DR» 24 
ERS» etc.}. This pre-Analysis activity may not divide cleanty 25 
between Feasibility and Definitions but generally Development 26 
activity on a GDS sufficientiy detailed to win approval cannot 27 
begin until PLM and Marketing have established the market 28 
feasibility for the proposed product or proposed product 29 
enhancement. 30 
31 

If: the proposal is deemed feasibles then Development. SI 32 
deliverable documents of the phase are: 33 
- Project Plan chapters 1 and 7.. SSTTJ 34 

- GDS Cinitial version) or other documentation describing STTJ 35 
the product. in general termss for Marketing and PLM 36 
approvals. 37 

5 38 

The intent of the documents is to provide direction to the SI 39 
Definition. Phase. - 40 
41 

The primary activity of the feasibility phase will probabty be Sf 42 
an exchange of memos among interested parties concerning 43 
featuress architectures performances and interfaces to other 44 
products which constitute a goat for a feasible product. To 45 
be of permanent values the outcome of this exchange of memos 46 
Should be recorded in the GDS or other documents to be 47 
approved by PLMs Marketings and AHPD and/or SDD. 48 
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2e2 DEFINITION PHASE. 
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2e2 DEEINITION PHASE 


Development deliverables of the definition Phase are: 
- Project Plan chapter 2 (Analysis Phase) 
- GDS (final version) 


The purpose of the Definition Phase is to firm up the 
decisions of the Feasibility Phase into a coherent set of 
requirments (featuress performances architectures interfaces 
to other products) in a approved GDS. The object {or goal) is 
to provide a definition of the product and to provide design 
direction for the Analysis Phase. Prior to the beginning of 
the Definition phases design direction is not firm enough to 
result in an approved GDS» for PLM and Marketing are still 
determining the market feasibility of the proposed product. 
There may aiso be budgetary considerations that restrict the 
resources availabte to prepare a GDS» and these considerations 
may also detay the transition from the Feasibility Phase to 
the Definition Phase. 


Reuqirements analysis is one of the most difficult of at! 
software development activities [Boehm 1979]. 


Requirements anatysis is an arts not a sciences which seems to 
use the following sort of diatectical process: 
1e- The designer or design teams on the basis of the best 
and most complete information availabies proposes to the 
customer(s) a design thought to meet all requirements in 
an optimum fashion. 
2e The customer says the design wil! not do becaus@se.s and 
another requirement which the designer was unaware of 
(and possibly the customer too unaware of ovdefore 
thinking about it) crawls out of the woodwork. 
32 The designer reworks the designs possibly from scratch» 
but more likely by patching its and goes back to step 


le. 
4. The customer says that will not due becausees.es and back 
to step 2. 


ee and the process iterates on and on. 
If the designer is tuckys the process terminates in a coherent 
set of requirements (featuress performances architectures 
interfaces to other products). 


However, every requirement has a price and if the price is too 
high (low priority item conflicts with a high priority item» 
architectural structure is compromiseds impiementation cost is 
too muchs etcejs the "requirement" ceases to be a requirements 
ho matter how tenaciousty hetd theretofore. 
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2e3 ANALYSIS PHASE H2 5 
3 

| 4 

2e3el INTRODUCTION H3 3 
6 

The purpose of the Anatysis Phase is to finalize requirements I 7 
and to carry design far enough to insure there are no design 8 
problems in meeting the requirements spelited out in the DR» 9 
the ERS» and the Analysis Spec portion of the GID. 10 
ll 

Development deliverables are: SI 12 
- Project Plan chapter 3 SSTTJ 13 

- DR STTJ 14 

- ERS STTJ 15 

~ GID chapters ls 2s 3» and 5 (Analysis Spec) STTJ 16 

) 17 

If the software research literature is correct in claiming SI 18 
that a requirements bug caught after detivery of a product to 19 
a customer costs 270 times as much to fix as a coding bug and 20 
that a design bug costs 90 times as much to fix [McCabe 19801]> 21 
then Control Data should be able to save many maintenance 22 
dollars by doing a better job of generating and reviewing 23 
requirements and design: documents. 24 
25 

SASD (Structured <Analysis/Structured Designs €DeMarco 1978, SI 26 
Yourdon 1978]) emphasizes the difference between data flow 27 
anatysis (a definition $and requirements function) and 28 
structured design (a design function). 29 
30 

Experience with SASD during deveftopment of Advanced Systems ST 31 
Release 1 products resulted in very few products doing both 32 
data flow and structure charts. Projects converting from 33 
CY170 jad worked out their requirements during CY170 34 
devefopuent and had tittte need of data flow anatysis. 35 
Structure charts» on the other hands turned out to be useful 36 
for documenting designs though some projects found other 37 
techniquess such as state tabless of more value. 38 
39 

For Release 2s there are several techniques availables each SI 40 
with advantages and disadvantages relative to the differing 4] 
needs of various projects. 42 
43 

Beyond Retease 2s it may be possible to use a specification S 4&4 
language (such as BSL (Barber 19811) for anatlysis/design. 45 
; 46 

47 

48 
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20302 SA (STRUCTURED ANALYSIS) 


2e3e2 SA (STRUCTURED ANALYSIS) 


Structured Analysis fas defined and described by DeMarco) 
offers useful techniques of decompositions data 
transformationss and data dictionary. 


Decomposition is the technique of summarizing an entire 
program in a one-page context chart (to show data flow 
interfaces to other programs) and a one-page level 0 DFDs and 
then decomposing each process in the levet 0 DFD into tevel 1 
DFDs» and so on down to as many levels as are necessary to 
define each bottom-level process in structured English. 


Data . transformation is technique of showing (with 
decomposition of data: files into recordss records into 
segmentss segments or tables into data elements) how output 
data is derived (directiy or indirectty) from intermediate 
files: or tables and input datas and how intermediate files and 
tables are updated from input data. 


A data dictionary defines alt data elements and data 
aggregations. 


Structured Analysis can be of great help to a project in 
defining the functions to be performed and insuring that 
interface requirements. of users and other products are 
understood by the project and can be implemented by the 
project. 


SA is supported by computer tools. The Data Dictionary [DCS 
ID=ARH3980}. supports data descriptions and process 
descriptions. SASD Graphics [DCS I0=ARH3981] supports: Data 
Flow diagrams. 


203-3 IA (INFORMATION ANALYSIS) 


Information Anatysis offers the capability of defining data 
and. the forms of data permissibie during data 
transformations. It does not offer decomposition techniques» 
though IA can be used to define data at any tevel from the 
most abstract to the most detaiied. Nor does IA offer the 
capability to define data transformations (i.e.5 the algorithm 
by which an output or file ttem is constructed from input or 
other file items). 


Information Analysis may be useful for projects whose main 
task is to describe a data base leeges the LTADT projects the 
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SASD database to support Graphics and Data Dictionarys the 


Corporate Traffic project). 


IA is not supported by computer tools. IAF and ADAM are 
avaifabte for implementations but are rather complex to use as 


Analysis tools. 


20324 STATE TABLES 


State tables are a useful tool for compiex programs where the 
reaction to a given input ts a function of the internal state 


of the program. State tables have been used by 


Networks (to 


define protocoi+driven programs) and Fortran/VS (to define 
symbol table processing). State tables can be very heloful in 
uncovering error casesSs end casess and infrequent cases that 


may be overtiooked in the course of designs 


technique forces a took at ail possible 
possible states. 


because the 


for all 


While there is no computer tool specificaliy supporting state 
tabless the Graphics structure chart capability can be used. 


20305 DECISION TABLES 


Decision tables can be usefuls for the same reasons that state 


tabifes can bee Essentiallys a decision table 


for a program that has onty one state for a 


is appropriate 


set of 


inputs. For these cases» ail data input/output cases can be 


defined.. 


In the computer industrys there are COBOL-related 


decision 


tabte tootss but none seems widely used in Controt Data. 


20346 STRUCTURED TESTING 


Structured Testing [McCabe 1980] offers several 
checking requirement specifications: 


-~ Cause and Effect graphs (pp I[I-ll» I[1-12)3: 


techniques for 


For each 


cause mentioned in the ERS or Analysis Specs there 


should be one or more causes; for each 


should be one or more causes; and 


conditions). 


- Specification reviews (pp II-18 thru II-26) 
specifications are complete and coherent. 


effect there 
these should be 
coherent (specified by non-conflicting 


and/or 


to insure 
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2e3e7 DATA FLOW ANALYSIS VERSUS STRUCTURE CHART ANALYSIS SH3 1 
2 

It seems to be a matter of individual temperament that some I 3 
programmers prefer data flow anatysis while others prefer 4 
structure design. Few programmers seem temperamentally 5 
equipped to view both as equaily useful. This difference 6 
seems to have roots in a preferred position either that 7 
control flow is the ftogical consequence of data flows or that 8 
data flow ought to be the ftogical consequence of contro! fiow 9 
Cieess which has togical precedence: data flow or control 10 
fiow? which is the bosss from a requirements point of be 
view?) 12 
13 

The challenge of the Analysis Phase is to make sure that data SI 14 
flow requirements are understood prior to detailed designs 15 
otherwise the detailed design may not be able to support the 16 
requirements of the program. Hence DeMarco*s pifea to set 17 
aside design until! data flow has been analysed to the point 18 
where those specifying requirements have agreed that the 19 
proposed specifications meet the requirements. 20 
. 21 

The crucial point is that the DR and ERS not be subject to STI 22 
modifications during the design phases due to either 23 
management or the project having overlooked or misunderstood 24 
requirements. 25 
26 

| 27 

204 DESIGN PHASE H2 = 
. 2) 

The purpose of the Design Phase is to compiete design prior to I 30 
Imptementation (coding and unit test}. 31 
32 

Development deliverables are: SI 33 

- Project Pian chapter 4 SSTTJ 34 

- GID (final version) STTJ 35 

- BSLs for internal and external baseline documents STTJ 36 

) 37 

Evaluation. deliverable: Project Plan chapter 5 SI 38 
; 39 

Publications. deliverable: Manuals Test Plan SI 40 
41 

SB (Structured Design) is the principal methodology of designs SI 42 
as spelled out by Yourdon and Constantine. 43 
44 

$0 is supported by the SASD Graphics for SCTs (structure SI 45 
charts) and the SASD Data Dictionary for module descriptions. 46 
Module descriptions should be detaited enough so that there is 47 
no ambiguity or open question encountered by the programmer 48 
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who transtates the module description into code meeting CYBIL 
coding standards. This does not necessarily mean that the 
module descriptions are so detaited that each structured 
English statement is the equivalent of one or a few tines of 
code. 


Structured Testing (McCabe 1980] provides quidetines for SI 
reviewing design documents (pp IV-20 thru IV-36). 


It is recommended that each project prepare a Project Notebook SI 
setting forth procedures that all project members are expected 

to adhere to (e.ge» *NOS/VE Project Procedures and 

Conventions"). 


2-5 LMPLEMENTATION PHASE . H2 


The purpose of the Implementation phase is to generate code I 
which has been reviewed and unit-tested (Development)» to 

generate test programs and data (Evaluation)s and to generate 

drafts of external manuats (Publications). 


Development deliverables are: . SI 
- Source Code PL SSTTJ 
- IMS STTJ 
Evaluation deliverabites are: Test programs and data SSI 
Publications deliverabies are: Drafts of external manuals. “ SI 
Coding and code reviews wii be done in accordance with SI 


SDD/ARPH coding staandards. and procedures. 


The project should insure that the procedures of the Project | SI 
Notebook: are adhered to (or revise the procedures so that they 
are adhered tod. 


206 EVALUATION PHASE | | | H2 
Historicallys the function of Software Evaluation has been to I 
detect errors before a customer dids so Software Development 

could-correct bugs: before the software was submitted to an 

acceptance test or instalied at a user's site Metzger 19731. 

Within the perspective of SDOMs the function is somewhat. SI 
different. a 
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Whife some persons fook to proper design to result in bugtess 
code and a program that never had any bugs is a better program 


than one 
others 

Pinpoint 
to debug 


"During 


in which the bugs have been fixed (Mitts 19761» 


believe that the proper function of Evaluation is to 


the origin of errors in the devetopment process so as 
the development process [£€Deming 1981]. 


Juty 19815 Dr W Demings the man whose ideas inspired 


the revolution in quality in Japanese industry conducted a 
four-day seminar for Control Datae He said:. 

- 85% of product defects arise From the process” that 
produces the products not from the workers who 
immplement the processe 

- Everyone is already doing his "best". If you want fewer 
defectss you have to find a better process. 


= If 


you reach your current tlevel of defects through test 


and reworks you can find a process that 


= -TF 


-- achieves the same level of defects directiyvs 
without test and rework and 


-- is more profitable than your current process. 


you: search for its you can eventually find a process 


that 


“-- produces no defects 
- fs more profitabie than your. current process. 


- The bectsoce of your testing process is to determine the 
capability of your process (its inherent defect levet) 
so that you can improve it." CHuntwork 1981s page 5.2.1] 


If these remarks are to be taken seriouslys then for Release 2 
the various test plans should address how Evaluation wilt 


determine 


which part of the development process is 


contributing to each error encountered. In the literature of 


Software 


Engineerings these problems are discussed in [(80ehm 


1975] and [Boehm 1976] among other places. 


Test ptans are: 
- Project Plan chapter 5 Feature Test 
- PSTP (Product Set Test Piands SDD 
- System Test Plans AHPD 


Sources of errors to be identified inctude: 
- Requirements activity 


prot 


Within. 


Design activity 
Implementation activity 
Publications activity 
Evaluation activity 


each of these activitiess a possibile source of error 
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might be: 


- omi 


ssion or oversight 


~- misunderstanding 

~ poor documentation in a baseline document 

- poor documentation or documentation in an inappropriate 
document . 

- “fell between the cracks” and some aspect of SDM is 
deficient 


207 PUBLICATIONS PHASE: 


The Pubti 


cations and Graphics Division has procedures (for 


generating external baseiine manuals and other manuats for the 
ofanned code release. 


Development management and Publications management work 


together 
meet thei 


to establish a schedule such that both groups can 
r commitments for release. 


Major fttems of the interface between Development and Pubs have 
been mentioned in the phases above: 

- Internal basetine documents must arrive in Pubs on 
schedule inorder that Pubs prepare draft manuals on 
schedule. 

- BSLs to external baseline documents must arrive in Pubs 


on: 


schedute inorder that Pubs prepare draft ‘manuals on. 


schedule. 
~- Pubs drafts of manuais must arrive in Development = on 
schedule inorder that Development and Evaluation can get 
reviewed drafts back to Pubs in time for Pubs to make 
changes and still meet the Release schedule. 


The key 


document in providing this schedule is the Pubs 


"Manual Test Plan” prepared by Pubs during the Design Phases 
with aporopriate input from Development management. 


208 RELEASESACTIVITY PuASE 


Timely pretease of materiats to customers entails much 
coordination among Developments Evaluations Publicationss 


Software 


Manufacturings and Literature Distribution. 


The procedures for these activities are spelted out in the SDD 
Minti-procedures Handbook. 
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3-0 DOCUMENTS 


3-0 DOCUMENTS 


For each documents a brief description is givens followed by a 
tabfe of contents. Where appropriates these skeletal tables 
of contents: are based on CDC Standard 1.01-100 "Programming 
Project Management Standards". 


NOTE for any document containing a glossary: The ANSI 
Dictionary for Information Processing CANSTI X3/TR~1-77) 
defines technical terms not defined in the glossary of the 
document. 


he 


301 PROJECT PLAN 


Purposes. To describe an activity in terms of how it is to be 
dones when it will be dones what the cost wil! bes 
what other projects are constraineds and what are 
constraining projects. 


The Project Plan is a management document rather. 
than a technical document. It should include a 
minimum of technical detait about the product. 


The Project Plan is included in this USERS GUIDE in 
order to: 
- Standardize the format among SDD projects 
- Indicate the sequence in which chapters 
shoutd be written, and indicate the 
chronotogical retationship of Product Plan 
chapters with other documents 


Content: The project pian is. the controtiing project 
document and contains several parts. These inctude 
(allo may not be required for a given project): 


Chapter 1--Definition Phase Plan 
Chapter 2--Analysis Phase Plan 
Chapter 3--Design Phase Plan 

Chapter 4--Implementation Phase Plan: 
Chapter 5--Feature Test Pian 

Chapter 6--Post Mortem 

Chapter 7--References 
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Audience: 


Owner 3 


Author: 


Comments: 


Managers 

Planners 

Interfacing projects 
System test 
Development project 
Quality Assurance 


SDD Management 


Devetopment Project /Product Design (chapters 
ls 29397). 

Development Project (Chapter 4) 

Evaluation (Chapter 5) 

Development. Project /Product Design/Evaluation 
(Chapter 6) 


Alt the planning documents»s as well as the post 
mortems are included tn this one plane This makes 
the project plan more complete and meaningful. 
Since it is organized into chapterss the audience 
can go directiy to the part that Is of interest. 
Most of the chapters above are based on a document 
that used to be stand-atone. Due to the fact that 
these were stand-alones a great deal of redundancy 
was noted. Collapsing the documents into one 
eliminates this problem. 


The Definition Pian: describes objectives» 
defivwerabtes,s and schedules for the definition 
phases The Analysis Pian does likewise for the 
Analysis phase» The Design Pian consists of 
ob jectivess milestoness and resources needed for 
the design activity. The Implementation Pian 
contains: similar types of informations plus 
constraints» risks,» unit testing plans or 
directions and System Integrated Test (SIT) plans» 
if required. Descriptions of individual unit tests 
in the form of a matrix or a tist will be produced 
by the project and/or the design team. These 
details need not be part of the IPP. The Feature 
Test Pitan describes the activities to be performed 
by Evaluation to verify functional capabilities of 
a given product or features as weli as activities 
required to verify the product performance 
requirements as specified in the AD/R and the OR. 
The Feature Test Pian also tists resource 
requirementss constraintss risks» and testing 
mifestones. Plans for performing System Integrated 


revision 8 


PE RD OS OO 08 FE 90 F808 PE PE PE 1G PE PE PO C8 OF 88 F888 18 PE 80 PE C8 08 88 28 08 RE OO OF RO 90 88 Ee 


CODE 


35 


12238259. 


LINE 


SOON OU WN eH 


3-3 
USERS GUIDE 
09/23/81 CODE 
3.0 DOCUMENTS 
3.1 PROJECT PLAN 


Test (SIT) cycies should also be inctudeds if 
appropriate. SIT pians should be in response to 
the SIT ptans outtined in Chapter 4 of the project 
Plane As with the IPPs specific test descriptions 
and/or a test matrix are provided by the evaulation 
project or by the design team as a separate working 
document; these details need not be part of the 
FTP. The post mortem is an informal document that 
describes what went right with the projects what 
went wrong with the projects and what could have 
been done to rectify bad situations in the 
project. 


> Each chapter of the project plan can be considered $$ 
either as a stand-alone document or as a part of 
the whote. Chapters are completed and distributed 
at different points in times ands in the case of 
the Feature Test Plans are authored by different 
peopte. Note that information is not repeated in 
each of the chapters. For examples for each 
chapter that contains milestones, the choice of 
milestones should be oniy those needed by peopte 
other than: the author and the author's managers for 
examples interdependency milestones. In chapters 
ls 29 and 3 only start and complete dates may be 


required. Intermediate mitestones are not of 
general interest and quickly become obsoleted by 
the PERT. 
Table of Contents: | SST 
1.0 Definition Plan SSSTTJ 
1.1 Introduction STTJ 
Introduction to and summary of chapter 1. SIJ 


Relevant documents can be tisted here or in 
chapter 7. Can contain a short technical 
description of the products especially if 
the GDS does not yet exist. 


1.2 Deliverables STTJ 
Project Plan chapter 2 {Analysis Plan)s GDS» SI J 
and any other deliverables. 

1.3 Milestones STTJ 
Dates for starts DCS submittal, and approval! SIJ 
of each deliverabie document. 

1.4 Resources and Schedute STTJ 
Identify person/months of effort for each SIJ 


calender month for each deliverable. 
Identify any other resources need for the 
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phase. 

Constraints 

Identify any constraints upon schedute and 
resources. (These constraints appty to the 
phase resources and schedules not to the 
product.). 


Anatysis Phase Plan 

Introduction 

Introduction to and summary of chapter 2. 
Deliverables 

Project Pian chapter 3 (Design Pland» DR» 
ERS» GID chapter 1 (Anatysis Spec and Data 
Dictionary)» and any other detiverables. 
Miftestones 


Dates for starts DCS submittals and approval 


of each deliverable document. 

Resources and Schedule 

Identify person/months of effort for each 
catender™ month for each deliverable. 
Identify any other resources need for the 
phase. 

Constraints: 

Identify any constraints upon schedule and 
resources. (These constraints apply to the 
phase resources and schedules not to the 
product.) . . 


Design Phase Plan . 

Introduction. 

Give an abstract of chapter 3. 

Deliverables 

List what (documentation including GID 
chapter 2s etc.) will be produced as a 
result. of the Design phase. 

Db jectives 

State all the major goals that are to be 
accomplished during the design phase. State 
considerations that wil! affect designs such 
as SIS» implementation ltanguages etc. 
Methods 

State how {in procedural terms) the design 
will be done. 

Constraints. 

Resources 

Milestones... 

List milestones for the design phase only. 
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Imptementation Phase Plan 

Introduction 

Give an abstract of chapter - 

Deliverables 

State what will) be delivered by this phase» 
such as softwares documentations etc. 
Objective 

State what is to be accomplished during the 
Impfementation phase. 

Overview 

Give a brief product description (refer 
detaifts to documents which contain all the 
detaitss including chapter led. State 
assumptionss list a glossary if needed. 
Schedule {Or phase ptan for implementation) 
Discuss the methodoliagy of implementations 
and what will occur during successive phases 
of the implementation. Discuss SIT pians. 
Unit testing. 

Describe how unit testing wit! take place 
during the different phases of 
implementations and whether unit tests will 
be salvageable as candidates for a system 
test base. 

Contingenciess dependenciess risks. 
Resources 


- $tate resource requirements - number of 


people needed {at different phases if 
possibie)s machine times and anything else 
that affects implementation progress. 
Milestones 

State mifestones onry for the implementation 
plan. 


Feature Test Plan 

Introduction: 

Give an abstract of chapter 5. 

Product features to be eesee es 

Testing Methodotogy 

Testing Approach 

Discuss the approach to be used to select 
which features are to be tested and which 
(if any) are not to be testeds and identify 
which are to be tested. and which are not to 
be tested. 

Features of the product not testable. 


Documentation: 


Test Base code reviews 
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SIT plans (if any) 

Performance Testing 

Discuss what testing wil! be done to verify 
DR specifications. 

Constraintss riskss dependencies (peoples 
machine configurationss tools) 

Resource requirements 

Deliverables 

Testing software and documentation to be 
detivered as a resuft of this pian... 
Transmittal Criteria 

This is transmittal criteria for the product 
to be tested. Inctude final release 
criteria for the product also (from DR). 
Milestones 

List mifestones for the entire test base 
creation and testing of the product. 
Inctude mifestones for test base 
availabifity and transmittal. 


Appendix-A Feature versus test matrix. 

Awl Test Base Content 

Aelel Current tests 
Discuss the size and content of 
the test base, without going 
over each test in detail. Cover 
such things as: how targe the 
test base iss perpetuation of 
tests from the ofd test bases on 
what medium and in what form the 
test base is» a general 
‘categorization of the tests in 
the test bases and the test case 
naming convention. A blow by 
biow account of each test can be 
given in the test base matrix. 

Aele2 Modifications and conversions 
Discuss classes of tests that 
will be modifieds dependent on 


development» schedules» and 


. other criteria. 
Aeies3 Enhancements to existing tests 
Features that need to be covered 


but: are not by the current test 


base@e 
A.2 Feature versus test matrix 
List tests by name and 


feature(s) tested by each test. 
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629 Post Mortem 
This chapter is the result of meetings with 
development» integrations evaluations 
product designs and publications personnel 
who were invotved with the project. Topics 
to be covered should include: 
~ Anatysis Phase/Design Phase of the 
project 
- Imptementation Phase 
Strategy 
Positive Aspects 
Negative Aspects 
Code Reviews 
Staffing/Machine Usage 
Schedules 
Interactive Usage 
Tools 
Special Factors 
Release Mechanics 
~ [GE 
Test Strategy 
Other test topics 
Special Feature Testing 
Instaitation Decks 
- Publications 
Conctusions/Suggestions/Actions 
Total Project Cost Data 


720 References 
List all documents» memoss etc. relevent to 
each and afi chapters of the Project Plan. 


302 AQZR_ (ARCHITECTURAL OBJECTIVES AND REQUIREMENTS? 


Purposes To specify high-tevel requirements on a system-wide 
as well as product-wide scate; to be used as input 
to the DR and the test plans. 


Content: Describes System in general termss describes major 
functional efements and characteristics of the 
system In specific. termss and furnishes detailed 
specifics of the sytem definition. 


Audience: Managers | 
Product Design 
Development projects 
Corporate reviewers 
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Owner 


Author:. 


Evaluation 
Publications 


ADEC 
ADEeC 


Tabie of Contents: (See AD/Rs A1688) 


303 SIS. 


Pur pose? 


Content: 


Audience: 


Owners. 
Author:.— 


Enforcer: 


To insure a uniform interface across the operating 
system and the product set. 


Covers product-to-product>» product-to-user>» 
system-to-users and product-to-operating system 
interfaces. 


Managers 

Product Design 
Development projects 
Corporate reviewers 
Evaluation: 
Pubtications 


Product Design/Advanced Systems Design 
Product Design 


AD & C 


Tabte of Contents: (See SISs $2196) 


30% GDS. 


Purpose: 


Contents: 


To document prioritized objectives and design 
directions for a given product that should be met 
but are not official commitments. This document 
should address multipfe reteases of a product» 
jee. the product's life cycle. 


The GDS encompasses design directions performance 
predictions and test direction as currentty found 
in three separate documents. The GDS serves as 
input to the feature test plans the analysis and 
design specificationss the ERS» and the performance 
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Owner : 


Author: 


test plan. 

Development projects 

Product Design 

System test 

Publications 
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Purpose: 


1.0 Introduction 
Give an abstract describing the product and 
this document. 


239 Glossary 

3.06 Major Product Interfaces 
Discuss the external and internal 
interfaces of the product. 

4.0 Major Product Features. 


Discuss the major product features. 
5.0 Standards 
Discuss standardss such as ANSIs SISs AD/R» 
which affect this product. 
20 Publications 
20 Performance Considerations 
Discuss the primary performance objectives 
with regard to the design of this product. 
8.0 Compatibility. 
Discuss compatiblity across predecessor and 


possible successor products» and with 
elements. or concepts of the overali system 
{such as system control language 
compatibitity). | 

9.0 Migration 


Discuss migration/conversion. impacts and 
what means will be available to ease 
conversion/migration from predecessor to 
this product. 

10.0 Test Direction: 
Discuss general testing strategy. 


To document the commitment by the division (product 


designs develooments system test and publications). 


to produce software products that meet stated 
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requirements. 
Contents: See Corporate Standard 16:2:01203:011 


Audience: Corporate reviewers 
Managers 
Development projects 
System test 
Publications 
Product Management 


Owner: PLM (Product Line Management) 

Authors Product Design/Advanced Systems Design 

Tabte of Contents:. 
There is no flexibility in the generation of this 
document, Ali sections tisted beitow must. be 
present in the DR» even If “not applicable”™. PLM 


has stated that they wit! not review a DR that does 
not conform to the CDC Corporate Standard for DRs. 


put 
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Definition 
References 
Inter dependent Documents 
Technical References 
Standards 
1 Controt Data Standards 
2 National» International and Industry 
Standards 
Requirements 
Functional Requirements 
Functional Operational Features 
RAM Features 
Configurations 
1 Mininaum: 
2 Typical 
3 Maximum: 
4 Test 
Physical Characteristics (Hardware) 
Performance Requirements 
Operational Performance Characteristics 
RAM Performance Characteristics. 
Maintenance/Instaltlation 
ol Preventive Maintenance (Hardware) 
e2 Customer Performed Maintenance 
23 Capital Test Equipment 
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3e2e% Catendar Life (Hardware) 
323 Compatibility Requirements 
Ze3el Predecessor Products 
32322 Companion: Products 
32343 Similar Products 
330% Competitive Products: 
3-4 Inter dependencies 
3.5 Cost Objectives 
3.2521 Field Maintenance 
32502 Manufacturing Costs (Hardware) 
326 Product Verification: 
3.7 Delivery Support Requirements 
Ze7el Product Support Manuais 
3e7e2 Special Packaging 
34723 Release Media 
4.0 Master Project Authorization 
520 Attachments . 
Ae Statement of Compliance 
Be Standards Checkiist 
Ce Product Restrictions 
De Other. 
See Corporate Standard 10301:03:011 for more 
details. 
3e6 ERS 
Purpose: To define in detail the external characteristics of 


a software product or feature and to specify the 
user/system interfacee The ERS is used as input to 
the GID» the IMS» the feature test plan (Chapter 5 
of the Project Pliands and to external user 
manuals. The DR and GDS are inputs to the ERS. 


Audience: Managers. 
Development Project 
Evatuation. 
Product Design 
Publications 
OQwner:. Baseline Control Board 
Author:. Development Project/Product Design 
Table of Contents: 
1.0 Introduction 
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A brief statement describing the software 
and tts purpose. : / 
References . 

Feature Description 

Feature Name 

Abstract | 

Give a brief and concise description of the 
feature.: 

Description 

Compietety define the feature in detail. 
Inctude a description of its function and 
possibte usages a definition of the 
variables and options applicable to the 
features results expected from correct use 
of the features dependencies. of this 
feature on other features. 

Interfaces 

Identify and discuss any component 


interfaces with the users his programs or 


the operator that are created or affected 
by this feature. Inctude input and output 
formats of the feature. 
Aborts and Recovery . 


Discuss the manner in which the software 


and/or system will. react in abort 
situations that are caused by this 
feature. Inctude reaction of this feature 
to system and user initiated aborts. 
Performance 

Discuss how this feature will affect the 
performance of the component» software 
product or overall systems from an external 
point of views if it is helpful for the 
user to know it. Don't get into internal 
details. 

Product-tevei Description 

Interfaces to other Software Products. 


Discuss external references to other 


software. . 

Restrictions and Limitations. 

Discuss known restrictions and timitations 
introduced as a result of this program or 
enhancements at the users operators and 
programmer tevel. 

Errors 

List ati error diagnostics for the products 
including severity levels significances and 


corrective action for the user to take for 
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Contents. 
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Author: 


OO PO OO PE 20 TE TO 08 BB TE OB OD FO 20 08 DE OB BO 10 00 08 FETE 88 PE UF O48 PE FO OD 08 UE OE 1B 00 08 C8 OF 08 88 08 88 TE 18 00 08 28 08 04 0 


each error. 

6.0 Glossary (optional) 
Terms,» abbreviationss or symbols which have 
special meaning in this document. 


To describe the overali process performed by a 
software product ofr componente. This description 
covers major processess the flow of data through 
the products» and descriptions of the data objects 
that are manipulateds as well as documentation at 
the modute tevel--structure of the modules and the 
information that each passes or accesses. 


The GID consists of the Analysis Specification (AS) 
and the Design Specification (DS). 


Development Project. 

Design Team 

Product Design. 

Evatuation 

Product Desagn/Advanced Systems Design 


Development Project 


Table of Contents: 


Introduction 

Analysis Specification 
Overview 

Data Fiow Diagrams ({(DFDs) 
Context Diagram. 

Level O and lower DFDs 
Process Descriptions 

Data Structure Diagrams. 
Data Dictionary 

Design Specification 
Structure Charts 

Moduie Descriptions 

Data Structure Diagrams (if needed) 
Design Issues 

References 
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For a detailed description of the elements of a 
: GIDs see DCS 10253855. 
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328 PSTP_ {PRODUCT SET_TEST_PLANe FORMERLY SYSTEM TEST PLAN) 


Purpose: To tist build schedutes and 
given CCR or CPS release. 


plans for a 


Content: This plan outfines testing plans and requirements 


for a given. Product Set 


information that is not covered 
is noted here. Gne example 
information is instatlation 


SDD). Oniy 


in other documents 
this type of 
testing planning. 


Performance test descriptions and size of a feature 
test base are examples of information that should 


not be itncludeds since 
avaitabie elsewhere. 


Audience: Managers 
Publications 


Owner. Evaluation 
Author: Evaluation. 


Table of Contents: 


This outtine is extracted from 


information is 


Proposed COC 


Standard for system test plans COC-STD 1.201.110. 


Please refer to that standard 


desired. 


1.0 Scope 


This section. identifies 
covered by the test plan. 
Appticabte documents. 


Test Approach. 
Testable conditions 


WwW Wh 
ees 
~ Oo 


detaiis are 


the software 


This: subsection identifies the conditions 


that are to be tested 


covered by the 
inctude: 


Performance 
Resource Usage 
Stress Testing 
Avaitabitity 
Retiabitity 
Installiability 
Maintainabitity 
Qeperability 


the software 


Plane. Exampies 
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309 EMS 


Purpose: 


Content: 


Usability 
Compatibility 
Security 
Functional Operation (features) 
362 Testing Selection 
This subsection defines a rationale for 
selecting which of the conditions 


identified in the section 3.1 are or are 
not to be testeds and identifies which are 
to be tested and which are not to be 


tested. This section may refer to 
individual feature test pians for details. 
323 Testing Procedures. 


This subsection identifies the procedures 
that are to be used to execute tests» 
record results» report resuitss store test 
data and proceduress and document errors. 

4.0 Entrance and Exit Criteria 
There are three sets of criteria to be 
specified. These are: 1) minimum criteria 
to be satisfied to enter and remain in the 
system testing phases 2} the minimum 
criteria to be satisfied to exit the system 
testing phases and 3) the criteria for the 
software to become certified. This section 
describes the criteria which apply. 

5-0 Resource Requirements 
a) Personnel Requirements. 
b) Hardware Requirements. 
c) Software and Toots Requirements. 
d) Other Requirements. 

6.0 Schedules/Costs 

7208 Responsibilities 
Each activity described in the pian must be 
assigned to specific organizations or 
individuals. 


To describe the design of a product at all tevets. 
The IMS is a deliverabte and Is aftso used as a 
basis for product maintenance. 


The IMS consists of the final GID (Analysis Spec» 
Design Specs and Data Dictionary). 
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